New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

kernel/x86: merge "generic" into "legacy" #14944

Draft

ehem wants to merge 1 commit into openwrt:main from ehem:generic

+533 −1,076

Contributor

ehem commented Mar 20, 2024

There is a desire to reduce the time spent on x86 OpenWRT platforms. "generic" is most suitable for removal. The few systems which could use "generic" must now opt for "legacy" (or for a lucky few "64").

Closes: #14231

github-actions bot added kernel target/x86 labels

ehem commented

View reviewed changes

target/linux/x86/image/legacy.mk

@@ @@ -3,7 +3,7 @@ define Device/generic @@
                 DEVICE_MODEL := x86/legacy
                 DEVICE_PACKAGES += kmod-3c59x kmod-8139too kmod-e100 kmod-e1000 \
               	kmod-natsemi kmod-ne2k-pci kmod-pcnet32 kmod-r8169 kmod-sis900 \
-              	kmod-tg3 kmod-via-rhine kmod-via-velocity kmod-forcedeth
+              	kmod-tg3 kmod-via-rhine kmod-via-velocity kmod-forcedeth kmod-fs-vfat

Contributor Author

ehem Mar 20, 2024

Seems odd kmod-fs-vfat is presently absent from legacy anyway. This simply comes from generic.

ehem commented

View reviewed changes

target/linux/x86/legacy/config-6.1

Comment on lines +118 to +138

+              CONFIG_EFI=y
+              CONFIG_EFIVAR_FS=m
+              # CONFIG_EFI_BOOTLOADER_CONTROL is not set
+              # CONFIG_EFI_CAPSULE_LOADER is not set
+              # CONFIG_EFI_CAPSULE_QUIRK_QUARK_CSH is not set
+              # CONFIG_EFI_COCO_SECRET is not set
+              # CONFIG_EFI_CUSTOM_SSDT_OVERLAYS is not set
+              # CONFIG_EFI_DISABLE_PCI_DMA is not set
+              # CONFIG_EFI_DISABLE_RUNTIME is not set
+              CONFIG_EFI_DXE_MEM_ATTRIBUTES=y
+              CONFIG_EFI_EARLYCON=y
+              CONFIG_EFI_ESRT=y
+              # CONFIG_EFI_FAKE_MEMMAP is not set
+              CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER=y
+              # CONFIG_EFI_PGT_DUMP is not set
+              # CONFIG_EFI_RCI2_TABLE is not set
+              CONFIG_EFI_RUNTIME_MAP=y
+              CONFIG_EFI_RUNTIME_WRAPPERS=y
+              CONFIG_EFI_STUB=y
+              # CONFIG_EFI_TEST is not set
+              # CONFIG_EFI_VARS is not set

Contributor Author

ehem Mar 20, 2024

I believe 32-bit EFI implementations did exist. I'm a bit doubtful about including support in legacy, but generic did have it enabled.

Member

hauke May 9, 2024

I think efi is very uncommon on such systems, but I would keep it for now.

Member

hauke May 9, 2024

maybe remove it.

ehem commented

View reviewed changes

target/linux/x86/legacy/config-6.1

Comment on lines +201 to +209

+              CONFIG_HYPERV=y
+              CONFIG_HYPERVISOR_GUEST=y
+              CONFIG_HYPERV_BALLOON=y
+              CONFIG_HYPERV_KEYBOARD=y
+              CONFIG_HYPERV_NET=y
+              CONFIG_HYPERV_STORAGE=y
+              # CONFIG_HYPERV_TESTING is not set
+              CONFIG_HYPERV_TIMER=y
+              CONFIG_HYPERV_UTILS=y

Contributor Author

ehem Mar 20, 2024

This was present in generic. I suspect 32-bit kernels are rarely used in Hyper-V VMs, yet it had been enabled.

ehem commented

View reviewed changes

target/linux/x86/legacy/config-6.1

Comment on lines +350 to +367

+              CONFIG_PINCTRL=y
+              CONFIG_PINCTRL_ALDERLAKE=y
+              CONFIG_PINCTRL_BAYTRAIL=y
+              CONFIG_PINCTRL_BROXTON=y
+              CONFIG_PINCTRL_CANNONLAKE=y
+              CONFIG_PINCTRL_CHERRYVIEW=y
+              CONFIG_PINCTRL_DENVERTON=y
+              CONFIG_PINCTRL_ELKHARTLAKE=y
+              CONFIG_PINCTRL_EMMITSBURG=y
+              CONFIG_PINCTRL_GEMINILAKE=y
+              CONFIG_PINCTRL_INTEL=y
+              CONFIG_PINCTRL_JASPERLAKE=y
+              CONFIG_PINCTRL_LAKEFIELD=y
+              CONFIG_PINCTRL_LEWISBURG=y
+              CONFIG_PINCTRL_LYNXPOINT=y
+              CONFIG_PINCTRL_METEORLAKE=y
+              CONFIG_PINCTRL_SUNRISEPOINT=y
+              CONFIG_PINCTRL_TIGERLAKE=y

Contributor Author

ehem Mar 20, 2024

This would be rather rare in a legacy system, but again copying from generic.

ehem commented

View reviewed changes

target/linux/x86/legacy/config-6.1

		# CONFIG_SERIAL_MULTI_INSTANTIATE is not set
		CONFIG_SMP=y

Contributor Author

ehem Mar 20, 2024

SMP is uncommon on legacy systems, but anything P6 or later could do it.

ehem commented

View reviewed changes

target/linux/x86/legacy/config-6.1

Comment on lines +249 to +258

+              CONFIG_KVM=y
+              CONFIG_KVM_AMD=y
+              CONFIG_KVM_ASYNC_PF=y
+              CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y
+              CONFIG_KVM_GUEST=y
+              CONFIG_KVM_INTEL=y
+              CONFIG_KVM_MMIO=y
+              CONFIG_KVM_VFIO=y
+              # CONFIG_KVM_XEN is not set
+              CONFIG_KVM_XFER_TO_GUEST_WORK=y

Contributor Author

ehem Mar 20, 2024

I'm unsure kernel-VM was back-ported to function on legacy-class hardware. Yet this had been enabled in generic.

Member

hauke May 9, 2024

Maybe someone wants to use a 32 bit OpenWrt on a modern CPU in KVM.

Contributor Author

ehem May 9, 2024

The danger is it could bloat legacy to the point it was too big for actual legacy hardware. Between legacy hardware and 32-bit KVM, legacy hardware seems the more valuable target.

ehem commented

View reviewed changes

target/linux/x86/legacy/config-6.1

Comment on lines +489 to +514

+              CONFIG_XEN=y
+              CONFIG_XENFS=y
+              CONFIG_XEN_ACPI=y
+              CONFIG_XEN_AUTO_XLATE=y
+              # CONFIG_XEN_BACKEND is not set
+              CONFIG_XEN_BALLOON=y
+              CONFIG_XEN_BLKDEV_FRONTEND=y
+              CONFIG_XEN_COMPAT_XENFS=y
+              CONFIG_XEN_DEBUG_FS=y
+              CONFIG_XEN_DEV_EVTCHN=y
+              CONFIG_XEN_FBDEV_FRONTEND=y
+              CONFIG_XEN_GNTDEV=y
+              CONFIG_XEN_GRANT_DEV_ALLOC=y
+              CONFIG_XEN_NETDEV_FRONTEND=y
+              CONFIG_XEN_PRIVCMD=y
+              CONFIG_XEN_PVH=y
+              CONFIG_XEN_PVHVM=y
+              CONFIG_XEN_PVHVM_GUEST=y
+              CONFIG_XEN_PVHVM_SMP=y
+              CONFIG_XEN_SAVE_RESTORE=y
+              CONFIG_XEN_SCSI_FRONTEND=y
+              CONFIG_XEN_SYS_HYPERVISOR=y
+              CONFIG_XEN_VIRTIO=y
+              # CONFIG_XEN_VIRTIO_FORCE_GRANT is not set
+              CONFIG_XEN_WDT=y
+              CONFIG_XEN_XENBUS_FRONTEND=y

Contributor Author

ehem Mar 20, 2024

Of all the hypervisors, Xen was originally written to function on legacy-class hardware. The support may die off soon if it hasn't already been killed, but it did work.

ehem commented

View reviewed changes

Contributor Author

ehem left a comment

The configuration options from generic were copied to legacy. Quite a few of these seem rather implausible for a generic or legacy-class system, but they had been enabled.

This would need advice as to which of these to kill.

ehem mentioned this pull request

x86: add 6.6 as testing kernel #14868

Merged

Contributor

namiltd commented Mar 20, 2024

Also please prepare patches for kernel 6.6 so that the PR is ready for commit #14868

Contributor Author

ehem commented Mar 20, 2024

There wouldn't be much difference. Simply duplicates everything for 6.6. If this got approved quickly it might go in before #14868.

Contributor

namiltd commented Mar 20, 2024 •

edited

The order of approval is still a mystery to me ;)

Contributor Author

ehem commented Mar 21, 2024

Just as long as the order of operations isn't. What is really needed is opinions on which options should really be copied from generic. Rather a lot of those don't really fit even for late model i386-class machines (EFI is quite rare, the few machines with it could almost certainly support traditional x86 BIOS boot too).

Contributor Author

ehem commented Apr 2, 2024

I guess we could almost simply dump generic. The extra settings in generic are likely rarely used on non-amd64, whereas the late-model P4s should be on 64.

Any comments on whether any of these should be dumped instead of propagated to legacy?

ehem closed this

ehem deleted the generic branch

April 12, 2024 15:10


          kernel/x86: merge "generic" into "legacy"

18603c7

There is a desire to reduce the time spent on x86 OpenWRT platforms.
"generic" is most suitable for removal.  The few systems which could
use "generic" must now opt for "legacy" (or for a lucky few "64").

Closes: openwrt#14231
Signed-off-by: Elliott Mitchell <ehem+openwrt@m5p.com>

ehem restored the generic branch

May 8, 2024 02:19

Contributor Author

ehem commented May 8, 2024

Hmm, unsure why I deleted the branch. Perhaps didn't want markers hanging around in git, and goofed on which one #14944 was tied to. Automatically closing pull requests isn't helpful.

ehem reopened this

ehem force-pushed the generic branch from 0f9346e to 18603c7 Compare

May 8, 2024 03:54

Contributor Author

ehem commented May 8, 2024

The more I look at this, the more I'm favoring simply deleting "generic" instead of merging it into "legacy". The reason being "generic" has too many settings appropriate for a mid-end machine. Merging it into "legacy" may well bloat "legacy" enough that it no longer runs on most legacy-class systems. Whereas most systems which want those settings can instead run "64".

About the only thing possibly appropriate to merge into "legacy" is the Xen support. Xen could be used on genuine legacy-class hardware.

Member

hauke commented May 9, 2024

The build of the legacy target fails like this:

====== Make errors from logs/target/linux/compile.txt ======
  MTRR cleanup support (MTRR_SANITIZER) [N/y/?] n
  x86 PAT support (X86_PAT) [Y/n/?] y
User Mode Instruction Prevention (X86_UMIP) [Y/n/?] y
TSX enable mode
> 1. off (X86_INTEL_TSX_MODE_OFF)
  2. on (X86_INTEL_TSX_MODE_ON)
  3. auto (X86_INTEL_TSX_MODE_AUTO)
choice[1-3?]: 1
EFI runtime service support (EFI) [Y/n/?] y
  EFI stub support (EFI_STUB) [Y/n/?] y
    EFI handover protocol (DEPRECATED) (EFI_HANDOVER_PROTOCOL) [Y/n/?] (NEW) make[7]: *** [scripts/kconfig/Makefile:77: syncconfig] Error 1
make[6]: *** [Makefile:697: syncconfig] Error 2
make[5]: *** [/__w/openwrt/openwrt/openwrt/build_dir/target-i486-openwrt-linux-musl_musl/linux-x86_legacy/linux-6.6.30/Makefile:798: include/config/auto.conf.cmd] Error 2
make[4]: *** [Makefile:234: __sub-make] Error 2
make[3]: *** [Makefile:26: /__w/openwrt/openwrt/openwrt/build_dir/target-i486-openwrt-linux-musl_musl/linux-x86_legacy/linux-6.6.30/.modules] Error 2
make[2]: *** [Makefile:11: compile] Error 2
time: target/linux/compile#21.11#11.18#25.33
Error: Process completed with exit code 2.

Member

hauke commented May 9, 2024

The more I look at this, the more I'm favoring simply deleting "generic" instead of merging it into "legacy". The reason being "generic" has too many settings appropriate for a mid-end machine. Merging it into "legacy" may well bloat "legacy" enough that it no longer runs on most legacy-class systems. Whereas most systems which want those settings can instead run "64".

About the only thing possibly appropriate to merge into "legacy" is the Xen support. Xen could be used on genuine legacy-class hardware.

I would keep the virtualization support for xen, kvm and hyperv. You can run the 32 bit system on a modern CPU in virtualization. This may be used for testing generic stuff. I think we can remove the EFI support. It is very uncommon.

Member

hauke commented May 9, 2024

Please add a commit to remove CPU_CFLAGS_pentium4 from include/target.mk

hauke reviewed

View reviewed changes

target/linux/x86/legacy/config-6.6

               CONFIG_INTEL_GTT=y
               CONFIG_INTEL_IDLE=y
               # CONFIG_INTEL_IPS is not set
               # CONFIG_INTEL_MEI_GSC_PROXY is not set
               # CONFIG_INTEL_MEI_HDCP is not set
               # CONFIG_INTEL_MEI_PXP is not set
+              # CONFIG_INTEL_MENLOW is not set

Member

hauke May 9, 2024

Please run make kernel_oldconfig CONFIG_TARGET=subtarget to refresh the configuration.

Contributor Author

ehem commented May 9, 2024

I would keep the virtualization support for xen, kvm and hyperv. You can run the 32 bit system on a modern CPU in virtualization. This may be used for testing generic stuff. I think we can remove the EFI support. It is very uncommon.

This is likely better served by having qemu emulate more of the hardware and pushing virtualization on modern processors towards 64. I really want to simply toss generic in the garbage can and leave legacy where it is. Just I prefer to get some degree of approval before modifying this pull.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment